Amiga Tools 4

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Tools 4 / Amiga Tools 4.iso / tools / developer-tools / assembler / assembler-kurs / lektionen / lektion1.txt < prev next >

Wrap

Text File | 1996-03-24 | 71.8 KB | 1,165 lines

Vollständiger Assembler-Programmierkurs auf zwei Disketten By Fabio Ciucci (Randy/Ram Jam) - 1994/95 Für all jene, die jemals zu lernen versucht haben, Demos und Spiele zu schreiben, die die Hardware des Amiga vollständig ausnutzen wollen, es aber nie geschafft haben, entweder weil die Handbücher der Programmier- sprachen zu schwierig oder zu abstrakt geschrieben waren und die Source- Codes (Programm-Listings) zu wenig dokumentiert oder zu schwierig waren, oder für jene, die es noch nie versucht haben und und die es wundert, wie es zu schaffen wäre. Ich möchte all denen danken, die materiell und moralisch zur Entstehung dieser zwei Diketten beigetragen haben: Luca Forlizzi (The Dark Coder/Morbid Visions) Andrea Fasce (Executor/RAM JAM) Sirio Zuelli (PROXIMA DESIGN) Alberto Longo (Fields of Vision) Alvise Spano' (Aga/Lustrones) Nicht desto weniger jenen, die die Übungen getestet haben und feststellten, ob sie sie mehr oder weniger verstanden: Andrea Scarafoni, Federico "GONZO" Stango und andere. Zum Schluß möchte ich noch meine Freundin Kety grüßen, die darauf achtete, daß ich nicht zu viel Zeit vor dem Computer verbrachte. In meiner Karriere als Hobbyprogrammierer kann ich einige Demos/Intros für BBS als Meine bezeichnen, zum Beispiel "AMILINK.EXE" für die Datenbank "AmigaLink" oder für Clubs wie dem neuen "Amiga Expert Team". Meine größten "Werke" sind mein erstes Demo für das AGA-Chipset, "World of Manga", und "NAOS2, das ich für die Gruppe NOVA ACIES programmiert habe. Ich möchte vorausschicken, daß es irgendwie angebracht wäre, mindestens eine Grundkenntnis des DOS zu besitzen, mindestens gerade soviel wie nötig, um die Listings abspeichern zu können! Ihr müßtet dafür beim Kauf ein Handbuch mitbekommen haben... Kurzum, auf den Disks (seien es nun Harddisks oder Floppy) sind die Daten als "File" gespeichert, das sind schier endlose Reihen von Ziffern, die zusammen dann z.B. ein Graphicfile, ein Musikfile, einen ausfühbaren File, ein Listing usw. ergeben. Es ist außerdem darauf zu achten, daß eine nagelneue Diskette FORMATTIERT werden muß, bevor man auf ihr Daten speichern kann. Ist sie einmal formattiert, kann man darauf jeden Typ von File speichern, seien es nun Bilder von einem Graphicprogramm oder Texte (wie den, den ihr gerade lest). Ein File kann man von einer Diskette auf eine andere kopieren, man kann ihn löschen oder seinen Namen ändern usw. Auf einer Diskette haben so viele Files Platz, bis sie voll ist (so ein Wunder...), das entspricht in etwa 880kB. Das heißt, ich habe zwei Dateien zu ca 400kB platz, oder mehrere kleinere, Hauptsache sie überschreiten zusammen nicht die Grenze der 880kB. Des weiteren kann man auf der Disk auch ein bißchen Ordnung schaffen, imdem man sog. "Subdirectorys" anlegt, das sind kleine Abteilungen in denen man die Files legen kann. So wäre es denkbar, eine Subdirectory "Texte" und eine "Bilder" anzulegen, in die wir jeweils unsere Liebesbriefe an die Freundin geben bzw. unsere Bilder, die wir mit DPaint oder einem anderen Malprogramm zusammengeschmiert haben. Es ist ungefähr so, als wäre die Diskette/Harddisk wie ein Schrank, und die Subdirectorys sind deren Schubladen. Nun ist es aber auch möglich, innerhalb der Directorys noch weitere Directorys zu machen, also kann eine Subd. Files oder weitere Subdirectorys beinhalten. Um sich nun in dieser Struktur fortbewegen und verschiedene Operationen durchführen zu können, muß man einige Befehle kennen, die man über die Shell/CLI eingibt: Dir = Listet alle Files / Subdir. auf dieser Diskette/ Platte bzw. in dieser Directory auf Copy = Kopiert ein File Delete = Löscht ein File ( Geht vorsichtig mit diesem Befehl um!) Makedir = erzeugt eine "Schublade" (Subdir) Eine andere Methode ist die, alles von der Workbench aus zu erledeigen, dort sind die File als Ikons (Bildchen) und die Subdirs als Schubladen dargestellt. Weiters ist zu wissen, daß der interne Floppydrive "df0:" heißt, die externen "df1:", "df2:" etc. Die Harddisk heißt meistens "DH0:" oder "HD0:". Schneller geht´s, wenn man Utilities wie Directory Opus oder DiskMaster verwendet. Wenn ihr also ein Listing geschrieben habt, dann müßt ihr es auf einer (formattierten) Diskette oder auf der Festplatte (Harddisk) in einer Subdir speichern. Eine weitere Sache, die ihr wissen solltet, ist, wie man eine "autoboot"-fähige Diskette herstellt. Das sind jene Disks, die automatisch nach dem Anschalten des Computers oder nach einem Reset laden, wenn sie im Laufwerk eingelegt sind. Nehmen wir mal an, wir haben ein AUSFÜHRBARES Programm geschrieben, das den Namen "Mein_Programm" trägt und dieses auf eine Diskette kopiert. Um es nun automatisch loslegen zu lassen, wenn wir den Computer starten, müssen wir auf der Diskette eine Subdir mit dem Namen "S" erzeugen und darin einen Textfile mit dem Namen "startup-sequence" speichern, in dem eigentlich nur der Name des zu Startendem Programmes steht: Mein_Programm Die startup-sequence könnt ihr zum Beispiel mit dem gleichen Programm schreiben (editieren), mit dem ihr gerade diesen Text lest. Es fungiert auch als Text-Editor. Letze Sache: ihr müßt die betreffende Diskette noch "installieren", das passiert mit dem Shell-Befehl "install": Install df0: Oder "Install df1:" , wenn die betreffende Diskette im Laufwerk df1: liegt. Dies vorausgeschickt, kann mit den Anmerkungen begonnen werden: Anmerkung: Wenn ihr den Assemblerkurs auf die Harddisk installieren wollt, vergesst nicht, das File "TRASH´M-ONE16.pref" in eure S: Directroy zu kopieren. Er befindet sich in der s: Directory der Diskette. Anmerkung2: Wenn ihr die Listings ausdrucken wollt, beachtet, daß sie mit dem PowerPacker gepackt sind. Ihr benötigt also den PowerPacker Patcher, der in diesem Kurs benötigt wurde, er befindet sich in der Directory "C" dieser Diskette und heißt "PP". Um ihn zu installieren müßt ihr nur in eurer LIBS: -Directory die "powerpacker.library" haben und "PP" tippen. Die Listings sind selbstentkomprimierend (A.d.Ü : tut mir leid, ich kenne kein kürzeres Wort dafür) beim Start. In diesem Kurs werden verschiedene Argumente behandelt, wie der COPPER, die SPRITES, der BLITTER sowie das neue AGA-Chipset und die Graphickarte Picasso II. Auf der Disk 1 sind folgende Themen enthalten: 68000, Copper, Playfields und Sprites. Der Blitter, AGA und der Rest sind auf Disk 2 und 3, leider noch nicht ganz vollständig. Was die Verbreitung und Kopie dieser Diskette angeht, solltet ihr wissen, daß sie GiftWare/Shareware ist und nicht wirklich Public Domain. Damit meine ich, daß ihr den Kurs ohne Weiters euren Freunden kopieren dürft, Hauptsache, ihr VERKAUFT ihn NICHT, da die Rechte auf diesem Kurs beim Autor liegen, also bei mir, und nicht beim ersten Schlaumax, der auf der Arbeit eines anderen spekuliert. Es ist aber auch wahr, daß ihr ihn einzig und alleine zum Preis der einzelnen verwendeten, leeren Diskette verkaufen dürft. Falls ihr es aber schafft, nachher selbstständig etwas zu programmieren, dann habt ihr aus meiner Arbeit Nutzen gezogen, und ihr MÜßT mir in irgend einer Art danken, vor allem wenn ihr die reichsten Programmierer der Welt geworden seid (na ja, man kann ja nie wissen...). Dieser Dank liegt ganz in eurem Ermessen, am liebsten habe ich natürlich 10-DM-Scheine. Der rege Zufluß von Kies/Kohle würde mich (Fabio Ciucci) ermutigen, weitere Lektionen zu schreiben, und meinen Übersetzer (Martin De Tomaso), sie ins Deutsche zu übersetzen. Das Geld (mindestens 10 DM) schickt ihr bitte an ihn: Martin De Tomaso Nicolodistr. 24/3 39100 BOZEN ITALY ; Internet: mdetomas@inf.unitn.it Bitte habt Verständnis, daß wir aus technischen Gründen (Zeit, Uni) nicht imstande sind, eure Listings zu verbessern, genausowenig wie auf tausenden von Zuschriften zu antworten. Stellt euch mal vor, so ca. 50 Briefe am Tag vor euch liegen zu sehen, wenn ihr in die Uni gehen müßt und euch dann auch noch die Freundin steßt. Wenn ihr aber gute und brave Programmierer seid, und die Amiga-Szene retten wollt (hey Chaos, Mr.Pet, Tron, Azure, Touchstone, Wayne Mendoza, .... where are you? On the PC scene? ), dann könnt - oder MÜßT- ihr mit uns Kontakt aufnehmen. Was kostet es euch schon, ein altes Listing zu kommentieren? Habt ihr nicht gesehen, wieviele MB an Listings die Coder auf den PC´s hergeben? Man braucht nur die CD-ROM der PARTY4 und der ASSEMBLY94 ansehen, oder sie von Internet runterholen. Ein anderer Grund, uns anzuleuten wäre, daß ihr imstande seid, den Kurs GUT ins ENGLISCHE zu übersetzen (bzw. in irgend eine andere Sprache). In diesem Fall habt ihr ein Anrecht auf einen guten Prozentsatz (30% - 50%) des Profites, der von euch übersetzten Version. Ihr würdet mir auch einen großen Gefallen machen, wenn ihr diese erste Diskette allen weiterkopiert, die ihr kennt, auch wenn euch selbst persönlich Assembler nicht interessiert, da ihr somit anderen die Möglichkeit gebt, programmieren zu lernen. Ich habe beschlossen, den ASM - Kurs (ASM=Assembler) zu schreiben, weil 10000 Personen mich darum baten, und da ich es aus reinem Spaß tue, ist er auch in einer recht umstreitbaren Form geschrieben, aber den Anfängern wird es so leichter fallen, denn wenn sie einmal "drinnen" sind, können sie immer noch selbst die Argumente vertiefen. Wer hingegen Assembler schon seit längerem programmiert, wird die Lektionen teils lustig finden, teils auch gewisse Ungereimtheiten, deswegen rate ich denjenigen, sich sofort die Listings anzuschauen: dieser Kurs ist für die gedacht, die bei NULL starten. Aus eigener Erfahrung, und laut dem, was mir die zukünftigen "CODER" so sagen, liegen die größten Probleme in den ersten zwei oder drei Programmen, und darin alles zu verstehen, danach ist man selbst imstande, fortzufahren. Ich biete mich also an, den Personen, die nicht einmal wissen was der 68000er ist,beizubringen, Kugeln auf dem Bildschirm hin und her zu jagen und dort hüpfende Schriften anzuzeigen. Wenn die dann Programmierer bei TEAM 17 werden wollen, reicht es, wenn sie weitermachen und dazulernen. UM EIN SPIEL WIE GODS, PROJEKT X ODER ÄHNLICHES ZU PROGRAMMIEREN, DAS NICHT GERADE EIN FLUGSIMULATOR IST ODER EIN 3D-SPIEL MIT ROTIERENDEN WÜRFELN MIT TEXTURE-MAPPING ODER SINUS-TUNNELN á la STARDUST HABEN, REICHEN DIE MATHEKENNTNISSE DER MITTELSCHULE. Damit will ich jedem aus dem Kopf schalgen, daß er für die Assemblerprogrammierung des Amiga weiß Gott was für Mathematik braucht. Ich persönlich glaube, Mathes hat gar nix damit zu tun. Wenn man ein Mathematikprogramm schreiben will, ok, dann braucht man Mathematikkenntnisse, genauso wie wenn man ein Fußballspiel schreiben will, man Fußball kennen muß. Das Wichtige ist zu wissen, wie der Amiga funktioniert, seinen Prozessor kennen (beim Amiga ein Motorola 68000 oder größer), seine CustomChips (praktisch die Teile, die die Graphic auf den Bildschirm bringen und die Musik spielen). Ich selbst habe eine Kunsthochschule in meiner Stadt besucht, und habe die ASM-Programmierung gelernt, wenn ich in der Mittelschule war, es reicht also, die Zeit, in der der Amiga eingeschaltet ist, gut zu nützen, und nicht nur zu spielen: man muß nicht Informatik an der Uni studieren, denn dort bringen sie dir sowieso nicht das Programmieren von Demos und Spielen auf einem Amiga bei! Aber wieso sollte man lernen, Demos und Spiele zu programmieren? Und was sind überhaupt diese Demos? Also, was Spiele sind, wissen hoffentlich alle, deswegen kann man davon ausgehen, daß diejenigen, die Spiele selber programmieren, es satt haben, Spiele zu sehen, die nicht so sind wie man möchte, und man halt einmal sein eigenes machen will, Pixel für Pixel. Demo ist ein Synonym für "demonstration", praktisch "zeigen","beweisen", meist Graphic. Aber was zeigen, beweisen? Klarer Fall, die Power, die der Amiga in sich hat und die Bravour der Programmierer. Aber da gibt´s noch mehr: die Szene. Nein, nicht die Theaterszene, die Amiga-Szene, die "AMIGA SCENE" (englisch ist die offizielle SCENE-Sprache...). Stellt euch die Musikszene vor: dort gibe es verschiedene Gruppen, mit Sängern, Schlagzeugern etc. In der AMIGA-SCENE hingegen gibt es verschiedene CODER (Programmierer), GFX Artists (Graphiker), MUSICIANS (Musiker), die anstatt ein "VIDEO" als Beitrag zu drehen, ein Demo schreiben, das sich zu den anderen reiht, die von jemand anderem, zu einer anderen Zeit und in einem anderen Ort geschrieben wurden, fügen. Dann gibt´s da noch die SWAPPER und die TRADER, die jeweils diese Demos tauschen und über Post oder Modem verbreiten. Die produzieren zwar gar nichts, haben aber auch ihre Wichtigkeit in der Szene: etwas, was nicht zirkuliert, ist so, als ob es nicht existieren würde. Andererseits streben sie danach, selbst CODER, Graphiker oder Musicians zu werden, um selbst einmal bei einem Demo mitgewirkt zu haben. Es gibt viele Gruppen in der Amiga-Szene, die Mitglieder in der ganzen Welt haben, vor allem in Europa. Einige der bekanntesten Gruppen sind ANDROMEDA, BALANCE, COMPLEX, ESSENCE, FAIRLIGHT, FREEZERS, MELON DEZIGN, POLKA BROTHERS, PYGMY PROJECTS, RAM JAM, SANITY, SPACEBALLS... Zu Bemerken ist, daß jedes Mitglied einer Gruppe ein Pseudonym hat, ein sog. "handle". Kurzum, es sind Künstlernamen: zum Beispiel heißen sich zwei Programmierer der ANDROMEDA "Dr. Jeckyll" und "Mr. Hyde", einer der FREEZERS heißt sich "Sputnik", und dann sind andere von anderen Gruppen:Hannibal, Dan, Paradroid, Dak, Wayne Mendoza, Performer, Bannasoft, Laxity, Vention, Psyonic, Slammer, Tron, Mr. Pet, Chaos, Lone Starr, Dr. Skull, Tsunami, Dweezil..... Der vollständige Name besteht aus dem handle und der Gruppe, der man angehört, z.B.: CHAOS/SANITY, DWEEZIL/STELLAR, DAK/MAD ELKS, und so weiter. Ich bin in der Szene "RANDY/RAM JAM", aber klarerweise Fabio Ciucci für alle, die mit der Szene nichts am Hut haben, sonst wäre es wohl etwas verwirrend. Die Szene organisiert Partys, eine Art Begegnungs-Fete, wo die Gruppen ihre Demos vorführen, mit einer Art "Wettkampf" um das beste Demo, mit Bewertung und Preisen, auch in der Tausend-Mark-und-mehr-Gegend für die Gewinner. Einige Programmierer der Szene gehen mit der Zeit über und programmieren Spiele, die Argumente liegen ja sehr nah. So ist zum Bleistift der Programmierer von "BANSHEE" Hannibal/Lemon, von "ELFMANIA" ist es Saviour/Complex, die von "STARDUST" sind DESTOP/CNCD und SCY/CNCD, und die Liste ginge weiter und weiter... Auf jeden Fall, auf Disk zwei ist eine ganze Lektion nur über die SCENE enthalten. Um zur Assemblerprogrammierung zurückzukommen, ob ihr nun Spiele oder Demos auscodieren wollt, rate ich euch wärmstens davon ab, 3D-Routinen (Routine=Teil eines Listings, eines Programmes) zu studieren, da sie die komplexesten und somit die schwierigsten sind, und die ich selbst schlecht verdaue, nicht wegen der Programmierart, aber wegen der grausligen Matheformeln, die sie beinhalten. Aber Achtung! Ihr dürft auch nicht glauben, daß wenn keine Mathematik-Kenntnisse gefragt sind, ihr nun Elektronikgenies sein müßt und die Schaltpläne des Amiga durchbüffeln müßt! Das ist nur der Fall, wenn ihr eine Graphik-Karte ansteuern müßt, einen Videodigitizer oder ähnliches. Ich versichere euch, daß ihr getrost die Figur eines Bayern auf den Bildschirm holt und dazu eine Polka spielen läßt, ohne zu wissen, wo die Drähte ´rumführen!!!! Ich kenne Leute, die Assembler mit 12 gelernt haben, andere mit 30 oder 40, ohne sich jemals mit Mathematik befaßt zu haben und ohne Englischkenntnisse. GENAU! DENN AUCH DEN MYTHOS, PERFEKT ENGLISCH KÖNNEN ZU MÜSSEN,SCHLAGT EUCH SOFORT AUS DEM KOPF! Ich gebe zu, englisch zu können erleichtert die Arbeit manchmal schon, denn die ASM-Befehle sind Abkürzungen von Wörtern aus dem Englischen, wie SUB und ADD, was soviel wie Subtraktion und Addition heißt. Die Kenntnis der WorkBench und des AmigaDOS werden euch in der Programmierarbeit an und für sich nicht recht nützlich sein, da der Computer in Wirklichkeit ziemlich anders funktioniert. Einfach ausgedrückt, sind diese "Überstrukturen" das Betriebssystem, die in den Kickstart-Chips lokalisiert sind, und ohne die beim Einschalten nicht einmal die Bildschirmseite angezeigt würde, die verlangt, eine Diskette einzulegen. Die Fenster, die ihr seht und verstellt, sind das Ergebnis von tausenden Zeilen in ASM, die im Kickstart enthalten sind, zur Bestätigung reicht es aus, die Unterschiede zwischen Kick 1.3 und 2.0 anzusehen. Es hat sich nichts an den Disketten geändert, aber an den Kickstarts selbst. Wenn ihr Programme wie Deluxe Paint, Kontoüberwachung, Haushaltskasse oder Word-Processor schreiben wollt, also Programme, die unter der Workbench laufen sollen, mit all ihren Fenstern, Menues, Gadgets und Multitasking, dann rate ich euch, die Programmiersprache "C" zu lernen. Sie ist für eure Art von Tätigkeit besser geeignet, und ihr könnt ohne größere Schwierigkeiten eure Programme nach MS-DOS und WINDOWS konvertieren, im Falle, daß ihr unsere Freundin verlassen (oder verraten?) wollt. Wenn ihr aber von Graphicdemos mit springenden Kugeln, metallern glizzernden Schriften und Super-Soundtracks im Hintergrund fasziniert seid, und davon träumt, Spiele wie AGONY,LIONHEART, SHADOW OF THE BEAST, TURRICAN, APYDIA, PROJECT X, SUPERFROG, ZOOL, GODS, CHAOS ENGINE, XENON II, LOTUS ESPRIT zu programmieren, dann sollte klar sein, daß das nur in REINEM ASSEMBLER machbar ist!! Und es braucht keine speziellen Vorkenntnisse in Mathe, es reichen die üblichen Additionen, Subtraktionen, Multiplikationen und Divisionen, vielleicht manchmal eine Sinustabelle oder eine Kosinustabelle um zum Beispiel die Kugeln in einer gewissen Laufbahn flizzen zu lassen, sei es nun eine Parabelform oder sonst eine Art von Kurve. Diese Tabellen sind nichts anderes als eine Serie von Zahlen im Speicher, wie z.B. 1,2,3,5,8,10,13,15,18,23, die wiederum nichts anderes darstellen als die X-Position bei einer bestimmten Y-Position. Diese Serien von Zahlen, die Tabellen oder SINUSTAB, erzeugt der ASMONE auf Wunsch auch von selbst. Dafür gibt´s den Befehl CS, der, ohne genaues Wissen über Trigonometrie und ähnlichem Zeug, die Tabelle von selbst erstellt, es reicht ihm die richtigen Parameter zu übergeben, schlimmstenfalls probiert man halt so lange, bis es mehr oder weniger paßt. Solche SINUSTAB kommen in Demos und Spielen oft vor, da viele wellenartige Bewegungen nicht in diesem Moment berechnet werden. Wenn ihr aber davon träumt, Adventurespiele wie Monkey Island zu schreiben bzw. Managerspiele, in denen nur stehende Graphicseiten auftreten, und sich darin höchstens hie und da mal eine Figur langsam bewegt, in denen der Sinn des Spieles darin besteht, die richtigen Objekte oder Schriftzüge mit der Maus auszuwählen, dann ist auch C besser am Platz. Es wird auch leichter, es auf PC zu konvertieren, auf dem man dan leicht einen Haufen Geld verdienen kann. Andererseits wird C in den technischen Hochsculen unterrichtet, und sehr gut an den Universitäten, also machen schon die das große Geld. Anmerkung: Das Beherrschen des Assemblers des Amiga kann sich als sehr nützlich erweisen, wenn man in Zukunft auf ein anderes System umsteigt, das mit dem gleichen Prozessor arbeitet, eben dem 68000 von Motorola. Solche Systeme sind Apple MacIntosh und AtariST. Diese Systeme haben aber ein anderes Betriebssystem als das im Kickstart des Amiga enthaltene, und andere Chips für die Darstellung der Graphic und des Tons, also werden euch die erworbenen Fähigkeiten für den Prozessor, nicht aber für das andere Betriebssystem oder die anderen Graphic/Sound-Chips zu Gute kommen. Für diese müßt ihr immer von NULL beginnen. Aber auch bei Sprachen wie dem "C" bleibt euch das Erlernen der neuern Umgebung nicht erspart. Wenn ihr zum Beispiel ein Programm in C unter der Workbench schreibt, das ein Fenster öffnet, und darin Berge zeichnet, und ihr steigt auf PC-MSDOS um (grober Fehler!), dann könnt ihr den Teil des Programmes, der die Berge berechnet wiederverwerten, aber der Teil, der die Fenster öffnet, die Gadgets und ähnliches unter der Workbench verwaltet, ist zu verwerfen und komplett neu zu schreiben. Und ich versichere euch, auf ein anderes System umzusteigen und alles neu zu lernen kostet Monate wenn nich Jahre an Zeit. Anmerkung:Ein Programm, das in 68000er Assembler geschrieben ist, funktioniert tadellos auf höheren Prozessoren, man muß nur einige Dinge beachten. Wenn ihr noch da seid und lest, dann heißt das, ihr seid noch unerschrocken. Also beende ich das Aufzählen der Vorzüge des Assembler... (die Sprache an und für sich heißt ASSEMBLY, das Programm, das es compiliert nennt man ASSEMBLER, aber einfacherweise nennt man alles ASSEMBLER, auch die Sprache selbst). Als erstes wird Assembler immer die schnellste Sprache sein, was Geschwindigkeit der Programme angeht. Vor allem, wenn sie gut geschrieben wurden, werden sie immer schneller laufen als mit einem x-beliebigen anderen Compiler. Weiters kann man damit spezielle Grafikeffekte erzeugen, die es noch nie gegeben hat: ok, ihr könnt sie auch mit einem Titler erzeugen, aber halt immer nur die gleichen. Es ist nicht schwer zu erkennen, mit welchem Programm ein gewisser Effekt erzeugt wurde. Das gleiche gilt auch für die Demo Maker. Der Beste darunter ist der TRSI DEMOMAKER, und er hat zweifelslos interessante Effekte, aber inzwischen erkennt auch ein Kind eine Sache, die mit dem Demomaker gemacht wurde, weil da immer die goldene Schrift oben und unten auftaucht, und in der Mitte entweder die Kügelchen oder die Sternchen... JETZT REICHTS! Man kann´s schon bald nicht mehr seh´n! Aber mit Assembler kann man dauernd neue Effekte erfinden, die noch niemand gesehen hat, und man muß sich nicht darauf beschränken, unter einem Dutzend Vordefinierten auszusuchen, die schon tausende andere Personen verwendet haben und Privatfernsehn damit angehäuft haben. Um euch eine Idee davon zu verschaffen, was ihr alles anstellen könnt, möchte ich das Demo von SPACEBALLS "State of the Art" nennen, eines der bekanntesten Demos, weil es alle erstaunte wegen der stilisierten Mädels, die in Mitten von Spezialeffekten tanzten. Ist nicht Schwieriges zu programmieren. Wenn ein Programmierer genug Geduld hat, kann er sich auch an ein Spiel heranwagen, zuerst um es selber zu spielen, um das Spiel seiner Träume zu kreiren, um zu experimentieren, wieviele Männchen er bewegen kann, ohne Geschwindigkeitseinbußen, um die wahren Grenzen des Amiga zu finden, und, später, vielleicht ein kommerzielles Spiel auf die Beine zu stellen, das auch die Mitarbeit von Grafikern und Musikern erfordert. Weiters braucht es dann noch einen, der an der Werbetrommel rüttelt, denn die ist oft ausschlaggebender als der effektive Wert des Spieles, außer in einigen Fällen, in denen das Spiel einfach so toll ist, das es trotzdem zum Erfolg kommt. Wieso nicht ein Spiel für CD32 entwickeln?? Es reicht, ein AGA-Spiel zu machen, das die 600MB einer CD ausnützt, z.B. mit einer Art von "Film", die in Echtzeit im Hintergrund geladen wird, auf der sich ein Alles-Töten-Rambo oder ein Raumschiff bewegt. Es ist gar nicht so schwer, ein solches Spiel zu machen: das Chipset ist mehr oder weniger das gleiche, es sind nur einige Register dazuzulernen, der Prozessor unterscheidet sich um NULL komma Josef, und die Verwaltung der CD ist noch einfacher. Da gibt´s nämlich das "CD32 Developer Kit", zwei Disketten mit allem Nötigen, das unter den Programmierern zirkuliert. Im Endeffekt ist an der Schwelle zum 2000 Assembler noch an der Spitze mit dabei, und wenn, wie viele PC-Typen prophezeien, nur mehr CD´s die Welt regieren, wird auch der Amiga mit seinen CD´s aufwarten. Denn zur Zeit sind es ja noch vor allem die PC-Fanaten, die voll aufrüsten um nur noch CD-Games zu spielen und sich Slideshows von nackten Girls anzuschauen. Na ja, und wenn eines Tages ein eine Software auf CD für den Amiga hervorkommt, dann ist es möglich, daß alles mit einem uns nicht unbekanntem Assemblerkurs begann... Wenn man dann einmal versteht, wie die Dinge in Wirklichkeit laufen, kann man auch versuchen, die Spiele und Programme zu verändern. So habe ich einige Male ein Programm so veränert, daß es den virtuellen Speicher des A4000 verwendet oder habe ich gewisse Routinen von PD-Programmen verändert, so daß sie schneller liefen. Bei Spielen kann man die sogenannten Trainer schreiben, in etwa so, daß wenn Player 1 stirbt, er ein Leben dazukriegt und ihm somit zur Unsterblichkeit verhelfen. Um solche Spielereien aufzuziehen muß man aber schon einiges auf der Platte haben, und vor allem braucht es dazu eine Utility, die MS-Monitor genannt wird. Diese erlaubt das disassemblieren von Maschinencode, also das anzeigen von gewissen Teilen des Speichers, und wenn man dann genau den erwischt, in dem die Leben des Player 1 stehen, ist die Sache geritzt. Besser noch sind aber die Cartridges wie die ACTION REPLAY. MS steht für Maschinensprache, es ist praktisch die Sprache, die der Prozessor direkt verwerten kann und die der Assembler erzeugt. MS ist aber für uns Menschen extrem unverständlich, und so hat man sie in Assembler gekleidet, der uns alles sehr viel leichter macht. Diese Operationen sind aber wie schon gesagt, recht schwierig, und es hat auch keinen rechten Sinn, einfach auf geradewohl loszuhacken und zu versuchen, ein blaues Männchen grün werden zu lassen. Ich habe Typen erlebt, die ihre Zeit damit vergeudeten, blindlings mit MS-Monitoren und Cartridges darauf loszuschießen um Änderungen vorzunehmen, die eingentlich kein Mensch richtig verstand -sie selbst inklusive- nur um dann zu Behaupten, sie hätten weiß der Geier was für Verbesserungen an dem Programm/Spiel angebracht. Diese können heute immer noch nicht eine Grafik in Assembler anzeigen; im Jargon heißen solche Typen LAMER. Bringen wir mal alles auf einen Punkt: wenn ihr einer dieser klassischen 18 jährigen, bleichgesichtigen, buckligen Jungs ohne Mädels seid, und auf gut Glück mit einem MS-Monitor in den Intimitäten eures armen Amiga rumfuchtelt, und behauptet, ein großer Hacker zu sein, dann legt den Monitor bei Seite und folgt mir auf den rechten Weg. Auch ich habe auf dieser lächerlichen Art und Weise begonnen (aber mit 8 Jahren, nicht mit 18!), habe aber bemerkt, daß es zu nichts führt und somit begonnen, Bücher zu lesen ohne Seiten zu überspringen. *Anmerkung des Übersetzers: An diesem Punkt werden einige Bücher aufgezählt, die es (nicht) wert sind, unter die Lupe genommen zu werden, die meisten jedoch von italienischen Herausgebern mit ausschließlich italienischen Auflagen. Ich zähle sie trotzdem auf und verweise auf jene, die in englisch oder deutsch zu haben sind. Hätte jemand einen Beitrag, also wenn jemand ein Buch empfehlen kann, dann bitte schreib mir!!! Meine Adresse findest du auf der Diskette!! "IL MANUALE DELL´ HARDWARE DELL´AMIGA" Herausgeber IHT. Ist einen Versuch wert, eine deutsche Version zu suchen. Soll scheinbar mächtig gut sein! In ihm werden die Hardware-Bausteine wie CUSTOM-CHIPS und FLOPPY unter die Lupe genommen, Register beschrieben usw. Es ist aber mehr eine Ansammlung von abstrakten Daten und Tabellen ohne Beispielen, aber die findet ihr ja in diesem Kurs. Für die Register braucht ihr nur im ASMONE den Befehl "=C" zu tippen, und es kommen die Informationen über die Register $DFFXXX, sei es generell wie speziell: =C 040 gibt euch eine Zusammenfassung über das Register DFF040, das ist BLTCON0, ein Blitterregister. "HARDWARE REFERENCE MANUAL" nur in englischer Version. "ROM KERNEL MANUAL" nicht recht empfohlen für hüpfende Kugeln etc, nur wenn man in ASM unter der WorkBench programmieren möchte. Weiters gibts dann noch das "AMIGA GURU BOOK", wenn ich nicht voll daneben liege, in englisch, und weiter wie "Amiga Spiele Programmierung", "Amiga Assembler Praxis" ü.ä. Ich kann sie weder empfehlen noch abraten, denn ich kenne sie (noch) nicht. Wenn jemand genaueres weiß, dann weiß er ja, was er zu tun hat... *Ende der Anmerkungen des Übersetzers. Anmerkung: Wenn ihr hingegen nicht die bleichen MS-Monitor-per-Zufall-User seid, sondern gierige Forscher von neuen Spielen, die es zu kopieren und zu beenden gilt, und ihr Stunden damit verbringt, am Telefon zu hocken um euch über die Neuigkeiten zu informieren, und die restlichen Stunden damit verbringt, mit XCOPY zu kopieren und zu spielen, vielleicht immer mit eingeschaltenem Trainer um früher ans Ende zu kommen, dann ist es noch schlimmer als bucklig mit dem MS-Monitor zu sein: entweder ihr macht Schluß mit diesem atemlosen Kummer, immer auf der Suche nach Kopierbarem zu sein, oder ihr werdet immer überspannt und gestresst sein und nie erfahren, wieso sich die Figuren über den Bildschirm bewegen, und ihr werdet nie erfahren, wie man sich selber einen Trainer mit Menu und viel Trara macht, und ich versichere euch, wenn ihr mal einen Trainer für ein Spiel geschrieben habt, dann kratzt euch nicht mehr, das Spiel zu beenden, sondern nur zu verstehn, wie´s wohl läuft!!! Das ist der Unterschied zwischen dem Spieler und dem Erschaffer des Spieles, zwischen dem unterworfenem Volk und dem herrschendem Regime, das ihm quasi befiehlt, in schlaflosen Nächten Unmengen an Spielen zu Ende zu bringen, entweder mit oder ohne Tainer, und egal, welche Spiele, Hauptsache, es sind Neue und Viele, wenn möglich mit XCopy kopiert (verwendet mindestens einen besseren Kopierer, XCopy ist einer der schlechtesten!). P.S.: Weil wir grade von Mädels sprachen... Ich habe noch NIE was von einer Frau in ASM programmiert gesehen!! Wenn das gerade eine Vertreterin des weiblichen Geschlechtes liest, dann glaube ich, ist es ein weiteres Motiv, die Erste zu sein!! Wenn sich ein Mädchen für anderes als Tuschel über fremde Leute und Vetrinen von Geschäften interessieren würde, und fetzige Dinge in ASM schreiben, dann glaube ich, könnte sie so manchen Boy in eine Krise versetzen, da die meisten davon bei den (weinigen) Girls, die sie kennen, so sehr angeben, wie gut sie den Mauspointer über den Bildschirm bewegen, und ihnen vorgaukeln, mit der NASA in Verbindung zu stehen, weil sie glauben, die versteh´n eh nicht die Bohne. Meistens können die nicht mal ´ne Diskette formattieren. Ich möchte hier schon mal vorweg nehmen, daß die Lektion2.TXT mit ihren Beispielen die schwierigste von allen ist. Wenn ihr die überstanden habt, dann ist die Sache gelaufen. Denn schon ab Kapitel 3 beginnen wir mit den ersten Coppereffekten, und von da an werdet ihr schnell wie Kanonenkugeln sein. Also bitte ich euch, die ersten beiden Lektionen mit Ruhe zu verdauen, ohne Dinge zu überspringen und -wie bei Romanen- die letzte Seite am Anfang zu lesen. Es bringt nichts. Nun schau´n wir mal, was wir zum programmieren brauchen: -Der ASSEMBLER ist das Programm, das die Listings mit ihren Befehlen (ADD, SUB,...), für den Programmierer lesbar, in das Äquivalente von binären Zahlen übersetzt (für den Microprozessor lesbar). So wird z.B. der Befehl "RTS" in $4e75 übersetzt, usw. Das macht programmieren halbwegs menschlich, denn stellt euch vor, ihr müßtet jeden Befehl als Nummer auswendig wissen! Das würde programmieren in reiner MS bedeuten, es ist aber klar, daß es viel besser ist, in ASSEMBLY zu tippen! Der nun entstandene binäre Code wird Objekt-Code genannt und ist direkt vom Computer ausführbar. Man kann ihn als ausführbares File abspeichern oder direkt testen. Ach ja, erinnert euch auch, daß in Assembler die Numerierung in Hexadezimal gängig ist! Hex-Zahlen sind jene, die das "$"-Symbol am Anfang stehen haben. Sie arbeiten mit der Basis 16, im Gegensatz zum Dezimalsystem, das mit Basis 10 arbeitet, das heißt, es kommen auch die Buchstaben A,B,C,D,E,F vor, wie im vorherigen Beispiel $4e75. Es ist egal, ob die Buchstaben groß oder klein geschrieben sind, $4e75 ist identisch mit $4E75. Wenn in einem Listing "Grammatik"-Fehler vorkommen, dann weist uns der Assembler darauf hin. Denn es gibt einige präzise Regeln, die einzuhalten sind. So z.B. muß ein LABEL (oder Etikette) am Anfang einer Zeile stehen, es dürfen keine Leerzeichen davor sein, und es muß mit einem Doppelpunkt (:) enden. Ein korrektes Label sieht so aus: PLUTO: Der Name kann nach Belieben vergeben werden, und PLUTO geht gut, denn es beinhaltet keine komischen Zeichen wie +-=^ usw, es beginnt am Anfang einer Zeile und endet mit :. Labels werden im ganzen Programm an "Dinge" vergeben, und sie dienen dazu, diese Dinge zu merken, sie zu finden, wenn man sie sucht. Wenn man innerhalb des Programmes einer Reihe von Befehlen den Namen PLUTO gibt, und dann zu irgend einem Zeitpunkt den Befehl gibt, Pluto auszuführen, dann werden die Instruktionen darunter abgearbeitet. Genauso können wir einem Bild oder einem Musikstück ein Label geben. Die Labels stellen also die Speicherstelle dar, an der etwas liegt, genauso, wie Städtenamen die geographische Position der selben angibt! Wenn ich nach Sidney gehen will, dann gehe ich da hin, wo das Label Sidney: steht. Erinnert euch aber, daß Labels nur uns Codern als Gedächtnisstütze dienen, der Assembler verwandelt dann alles in Zahlen, seien es nun Befehle oder Labels (die ja nur Speicherstellen sind und somit eine Adresse, eine Haus-"Nummer" haben). Dann gibt´s noch die Befehle, die IMMER von einem oder mehreren Leerstellen vorangegangen werden muß, besser noch von einem TAB, der gleich 8 auf einen Schlag macht (es ist die Taste über CTRL), gefolgt von den Operanden. Pluto: MOVE.L $10,$20 In diesem Fall ist MOVE.L der Befehl (oder Instruktion), während der erste Operand $10 ist und der zweite $20. Manche Befehle brauchen nur einen Operanden, andere überhaupt keinen, z.B.: CLR.L $10 Nur ein Operand. Befehle wie RTS brauchen z.B. keinen. Dann ist da noch der Kommentar, der uns hilft, zu erinnern, was wir gerade tun: er wird immer nach einem Strichpunkt (;) geschrieben. Pluto: ;LABEL, stellt die Adresse von MOVE dar MOVE.L $10,$20 ;Befehl mit 2 Operanden CLR.L $10 ;Befehl mit 1 Operand RTS ;Befehl ohne Operanden Die Kommentare werden beim assemblieren verworfen, also könnt ihr schreiben, was und wieviel ihr wollt, Hauptsache nach dem ;. Das war die Grammatik. Nach diesen einfachen Regeln wird das Programm erzeugt, und ob es dann tut, was ihr wolltet, hängt dann ganz von euch ab! -Ein EDITOR hingegen ist ein Programm, das euch ermöglicht, Texte zu schreiben und zu modifizieren, in unserem Fall werden wir damit die Listings schreiben, die ja nichts anderes sind als Text, der die Befehle (Move, Sub,...) und die Kommentare enthält. Bessere Editoren haben dann Such- und Ersetzoptionen, mit denen gewisse Zeichenfolgen gesucht und ersetzt werden können. Normalerweise endet der Filename von ASM-Listings mit .ASM oder .S. Ich bevorzuge .S, TExte, die zum lesen bestimmt sind, enden mit .TXT. Der Name des File aber beeinflußt in keiner Weise die Funktionsweise des Assemblers, der frißt alles. -Ein MONITOR ist in diesem Fall nicht die Glotze des Computers,sondern ein anderes Programm, das euch ermöglicht, die Inhalte des Speichers zu sehen, z.B. was auf Speicherzelle $100 steht usw. Normalerweise haben Monitore auch einen DISASSEMBLER, das Gegenteil des Assemblers, mit integriert, das das Sehen des Speichers als Befehlen erlaubt. Er verwandelt also MS in Assembly, er verwandelt $4e75 in "RTS". -Ein DEBUGGER, wortwörtlich "Entwanzer", dient dazu, ein Programm Befehl für Befehl durchzugehen und zu testen. Damit findet man meistens die Stelle, an der ein Fehler liegt. Manchmal muß der Objektcode, um einwandfrei unter dem Betriebssystem zu arbeiten, gelinkt werden, denn ein ausführbares File enthält nicht nur einen Block von Befehlen, sondern auch Angaben darüber, wie er in den Speicher geladen werden soll. Das geschieht mit dem LINKER. Das gilt für .EXE und .COM Files unter MSDOS genauso wie bei allen anderen Betriebssystemem. Das ist auch der Grund, warum unter Atari oder MacIntosh Amigafiles nicht gelesen werden, obwohl sie den gleichen Prozessor besitzen: weil das Format eben anders ist. Speziell unter dem Amiga gibt´s die HUNKs, und um Objectcode durch Mausklick oder Shellbefehl ausführbar zu machen, müssen sie gelinkt werden. Zum Glück haben die meisten Assembler den Linker eingebaut, und ihr müßt euch nicht darum sorgen! Gut, der Assembler, der diesem Kurs beigefügt ist, der TRASH´M´ONE, hat einen Editor, einen Assembler, einen Debugger/Monitor und einen Linker!!! Alles in einem, was will man denn mehr! Es ist die modifizierte PD-Version des Asmone. Übrigens, zum Editor, ihr könnt einen Text suchen, indem ihr die Tasten AMIGA rechts+Shift+S gleichzeitig drückt, oder mit der rechten Maustaste aus dem Menue die Option SEARCH unter dem Titel "Edit Funkt." auswählt. Nun erscheint links oben die Schrift "Search for:", wo ihr das -oder dieWorte eingebt, die ihr suchen wollt. Es kann nützlich werden, z.B. um die Stelle wiederzufinden, an der ihr aufgehört habt, zu lesen, in diesem Fall Zeile 592 (wird links unten angezeigt), oder ihr sucht das Wort "Funkt." oder "Zeile 592" oder was euch grade einfällt. Natürlich hätten wir normalerweise das Listing mit einem Editor schreiben müssen und mit einem beliebigen Namen abspeichern.Dann mit einem Assembler laden, assemblieren und den Objektcode speichern. Um das Programm dann zu guter Letzt testen zu könne, kommt auch noch das linken dazu. Um es verändern zu können, wieder mit dem Editor laden, speichern, usw. bis zur Vergasung. Auf den PC-MS-Dosen ist das so der Fall, und ich hab´s aufgegeben, dort in Assembly zu programmieren. Aber beim Amiga, mit Multitasking kann man gleichzeitig Editor und Assembler laden, etc. Und, als würde das noch nicht reichen, hat jemand den ruhmvollen SEKA erfunden, ähnlich dem jetzigem ASMONE, der Editor, Assembler und Monitor alles in einem hatte. Dann ging die Entwicklung weiter zum MasterSeka, dann zum ASMONE und dann endlos viele, von Hobbyprogrammierern modifizierte, Versionen dessen. Die zwei verbissensten Verbesserer (die sind wirklich gut!) sind die TFA die den TFA ASMONE hervorgebracht haben, und DEFTRONIC, die diesen TRASH´M´ONE ins Leben riefen. Ich habe den von DEFTRONIC ausgewählt, weil er am wenigsten BUGS (Fehler) hat, denn die meisten anderen Versionen assemblieren oft saDFSDAF SADFFDSASAD, aber man kann es ihnen ja nicht verübeln, denn sie tun es ja aus purem Spaß, ohne etwas zu verdienen! Das Endergebnis ist also, daß ihr ein Listing eintippen könnt, und dann, mit ESC, zum Assembler/Monitor überwechseln, und dort (mit "A") assemblieren oder den Speicherinhalt ansehen, sei es nun als Zahlen oder als Befehle dargestellt, und zum Schluß -aber nicht weniger interessant- disassemblieren. Um das ausführbare File direkt abspeichern zu können, tippt "WO" in der Kommandozeile (das ist die Zeile, die ihr erreicht, wenn ihr mit ESC den Editor verlasst). Damit keine Verwechslungen auftreten, stellen wir noch mal klar, daß es einen Unterschied zwischen Listing und Programm gibt: das Listing ist ein Text, der die Befehle/Anweisungen in ASM enthält, und es ist mit jedem Editor editierbar, z.B. dem CED oder GoldED.Das Listing wird durch "W" abgespeichert. Das Programm hingegen ist das schon assemblierte File, es ist von der WorkBench/Cli/Shell ausführbar, es hat schon den Hunk angehängt etc. Abspeichern durch "WO". Der Editor im ASMONE ist also nur ein Editor wie alle anderen, ihr könnt damit auch die Startup-sequence ändern oder einen Brief an eure Mutti schreiben. Alsodann, jetzt werde ich -auf meine Art- mit den Erklärungen fortfahren, wie der Computer funktioniert. Derjenige, der alles organisiert ist der Prozessor, oder CPU (Central Processing Unit), praktisch der Boss...Er führt Befehle aus, in der Tat besitzt er ein genaues Set von Anweisungen, die er ausführen kann, nur die und keine anderen. Er geht dabei immer der Reihe nach, erst eine, dann die nächste, usw., außer man befiehlt ihm, nach weiter vorne oder hinten zu springen, oder eine Schleife (Loop) auszuführen. Einige Befehle (Anweisungen) sind: MOVE, das soviel bedeutet wie bewegen, hier aber als "kopieren" zu interpretieren. Move $10,$20 sagt also "Kopiere das, was in $10 (Adresse/Speicherzelle) nach $20" aus. Dann CLR, Abkürzung für Clear, also Lösche, setze auf NULL: CLR $10 -> lösche die Adresse/Zelle $10. Als Adresse, Speicherzelle oder Zelle meine ich einen Punkt im Speicher, der dem Prozessor zugänglich ist. Übrigens, der Prozessor operiert im Speicher!! Erstellen wir also eine Art "Karte" darüber: Wenn die Befehle mit Adressen herumhantieren, die kleiner als $200000 sind, dann befinden wir uns im CHIP RAM. Von $000000 bis $80000 befinden sich die ersten 512kB Chip Ram, also die der alten A500 und A2000, wenn die Ram aber bis $100000 weitergeht, haben wir 1MB Chip Ram, wie z.B. die A500+, A600 oder die neueren A2000. Bei den A1200, auffrisierten (erweiterten) A500+ oder A600 hingegen reicht die Chip Ram bis $200000. Also sind Befehle unter $200000 in der Chip Ram: CLR.L $30000 MOVE.L $150000,$1a0000 Das waren Instruktionen, die in der ChipRam arbeiten. Wenn aber mit Adressen über $200000 gearbeitet wird, dann befinden wir uns in der Fast Ram. Ein alter A500 mit 1MB Speicher ist in zwei Blöcke zu 512kB (512kB Fast + 512kB Chip) aufgeteilt: 1) von $000000 bis $80000 ;ersten 512kB CHIP RAM 2) von $c00000 bis $c80000 ;512kB FAST RAM Mit Utilities wie SYSINFO könnt ihr feststellen, wie eure Speicherblöcke verteilt sind. Dann existieren noch spezielle Speicherzonen, wie in etwa die der ROM, also des Kickstarts. Die beginnt normalerweise bei $fc0000 für Kick 1.2 und 1.3 und $f80000 für Kick 2.0 und 3.0. Die ROM kann im Gegensatz zur RAM nur gelesen, nicht aber überschrieben werden. Sie bleibt auch nach abschalten des Computers intakt. Eine extrem wichtige Adresse ist noch $DFF000, denn von $DFF000 bis $DFF1FE sitzen die CUSTOM CHIPS für Grafik und Sound. Um eine Grafik anzuzeigen oder Musik spielen zu lassen, muß man in die Adressen $DFFXXX die richtigen Werte schreiben, sonst passiert gar nix. Diese speziellen Adressen werden auch REGISTER genannt. Probiert mal, in der Kommandozeile (mit ESC schaltet ihr zwischen Kommandozeile und Editor um!) den Befehl "=C" einzutippen, ihr werdet eine Zusammenfassung der Register mit ihrer Adresse erhalten. Die Zahlen sind die Adressen, 000 steht für $DFF000, 100 für $DFF100, und die Namen sind daneben geschrieben, z.B. ist $dff006 VHPOSR, und $dff100 BPLCON0. Diese Adressen kann man entweder nur beschreiben oder nur lesen, z.B. $dff006 ist nur lesbar, $dff100 nur beschreibbar. Ihr werdet zwischen Zahl und Namen entweder ein W oder ein R stehen sehen : W (write) -> nur schreiben, R (read) nur lesen. Andere sind S (strobe) oder ER (EarlyRead), wir werden sie besprechen, wenn wir sie verwenden. Weitere Spezialadressen befinden sich in der Gegend von $bfeXXX, genau gesehen von $bfe001 bis $bfef01. Sie beziehen sich auf den Chip CIAA, der verschiedene Dinge beinhaltet, wie den Timer oder die Kontrolle über verschiedene Ports, z.B. den Parallelport, das ist der, an dem der Drucker hängt. Analog dazu gibt´s die CIAB, sie hängt an den Adressen $bfdXXX. In Erinnerung behalten müßt ihr eigentlich nur, daß wenn ihr eine Adresse vom Typ $bfeXXX, $dfdXXX oder $dffXXX seht, sie sich auf die CustomChips bezieht, die Farbänderungen auf dem Bilschirm zur Folge haben, oder Bewegungen von Maus oder Joystick einlesen uvm. Was die RAM angeht, sei es nun CHIP oder FAST, braucht ihr euch nicht darum zu kümmern, wo welcher Befehl landet. Das erledigt für uns der ASMONE, wir müssen lediglich einige LABELs verteilen,um gewisse Stellen zu markieren, danach ersetzt der Assembler sie mit den realen Adresswerten. Wen´s interessiert, er kann danach nachschauen, wo die Instruktionen gelandet sind. Aber fahren wir mit den Beispielen fort: Es gibt Befehle wie ADD und SUB, die soviel wie Addition und Subtraktion bedeuten, un so bedeutet z.B. SUB #10,ENERGIE "ziehe von ENERGIE 10 ab". Weiters Multiplikationen und Divisionen wie MULS, MULU, DIVS und DIVU und die logischen Operationen OR, AND NOT und andere. JMP bedeutet JUMP ("Springe"), also springe zu einer bestimmten Adresse (z.B. JMP $40000), JSR hingegen veranlasst den Prozessor, zu einer Routine auf einer bestimmten Adresse zu springen und diese durchzuführen, bis er einem RTS begegnet (JSR "Jump to SubRoutine" -> "Springe zu SubRoutine"), (RTS "Return from Subroutine" -> "Verlasse SubRoutine, kehre zurück"). RTS steht also für "komm zurück, die Routine ist fertig", und die Abarbeitung des Programmes fährt nach dem JSR wieder fort. BRA tut im Wesentlichen das geliche wie JMP, BSR wie JSR. TST heißt "Test" (gegenüber NULL), es testet also eine bestimmte Adresse oder ein Register, ob es NULL ist. Diese Instruktion oder die Instruktion CMP ("Compare", ->Vergleiche), die etwas mit etwas Anderem vergleicht, ist normalerweise von einem sog. "Bedingtem Sprung" gefolgt: z.B. BEQ ("Branch if Equal" -> "Springe wenn Bedingung erfüllt") oder BNE ("Branch if not Equal" -> "Springe wenn Bedingung NICHT erfüllt"). So kann man verschiedene Verzweigungen erzeügen, hier ein dummes Beispiel: Anfang: BSR GLOCKEN ; BSR -> springt bis unter das Label "GLOCKEN" ; danache kommt er hierher zurück und führt WarteMaus aus BSR WarteMaus ; Wartet, bis Mausknopf gedrückt wird BSR PAVAROTTI RTS ; verläßt das Programm, kehrt zum ASMONE oder zur Workbench zurück, jenachdem, von wo aus es gestartet wurde. WarteMaus: Hier wird kontrolliert, ob der Mausknopf gedrückt wurde. Wenn NICHT, springt er zu WarteMaus zurück, er läuft praktisch im Kreis, bis der Mausknopf gedrückt wird, wie ein Hund, der versucht, seinen eigenen Schwanz zu fangen. In diesem Fall werden wir ein "BNE WarteMaus" verwenden. RTS ; Ende der Subroutine, kehre unter das ; aufrufende "BRS" zurück GLOCKEN: DingDong ; eine Routine, die "DingDong" spielt RTS PAVAROTTI: AAAAAAAHHHHHHHHH ; Diese Routine läßt den Pavarotti singen RTS END ; zeigt das Ende des Listings an, kann man ; auch weglassen (Was unter dem END geschrieben wird, wird vom Assembler nicht gelesen) Also, wenn wir dieses hypotetische Programm starten würden, dann könnten wir sagen, daß es bei "Anfang" beginnt, und diese Routine die Hauptroutine ist, die drei UnterRoutinen (SubRoutines, Teile eines Programmes, denen man einen Namen gibt, z.B. PAVAROTTI) der Reihe nach aufruft: als ertes würde der Prozessor zu "GLOCKEN" springen und die Glocken läuten lassen, dann findet er ein RTS, kehrt also unter das BSR GLOCKEN zurück, dort findet er aber ein weiteres BSR, das, das ihn zu WarteMaus bringt. Dort bleibt er, bis jemand die Maus drückt (eine Knopf davon, versteht sich...). Der Prozessor kontrolliert auch eine Milliarde mal, ob der Mausknopf gedrückt wurde, und erst, wenn das eintrifft, kann er die Routine verlassen, da der Endloszyklus unterbrochen wird, weil das BNE nicht mehr wahr ist. Am RTS von WarteMaus angekommen, hüpft er zum Hauptprogramm zurück, wo ihn schon das nächste BSR erwartet: PAVAROTTI. Wenn er dann vom Pavarottikonzert zurückkommt, findet er nur mehr ein RTS vor: für ihn bedeutet das, daß er aussteigen soll, zum ASMONE oder zur Workbench, jenachdem. Das Programm ist zu ENDE. Jetzt erkläre ich euch besser, wie der Prozessor sich mit den verschiedenen Befehlen verhält: Im Falle von "BEQ Label" sprechen wir von einer Verzweigung, denn an diesem Punkt gibt es zwei Alternativen: stellt euch einen Baum vor, so einen richtig alten und trockenen ohne Blättern, eine uralte Eiche mit einem knotigen Stamm, der sich an einem gewissen Punkt in zwei Äste unterteilt, und jedes der Äste verzweigt sich nochmal in zwei kleinere Äste, und so weiter. Wenn wir nun am BEQ ankommen, ist es, als wären wir eine kleine Ameise, die am Anfang des Programmes - also des Stammes - gestartet ist, wo unser Ameisenhaufen START: steht. Gut, wo wir nun zur VERZWEIGUNG: gekommen sind, müssen wir wählen, entweder den linken Ast oder den rechten. Diese Wahl trifft der 68000 auf Grund des Resultates einer vorherigen Bedingung, praktisch eines CMP oder eines TST: START: ; Ameisenhaufen im Gras ... ... TST.B LABEL30 ; ist das Byte von LABEL30 = 0 ??? (Beispielbedingung) BEQ RECHTERAST ; wenn ja, springe zu RECHTERAST ; wenn nicht (ungleich 0), dann fahre mit LINKERAST fort. (das bedeutet, das Byte hatte einen Wert zwischen $01 und $FF) ... ; Befehle von LINKERAST ... ... RTS ; ENDE, wir steigen aus. Wir haben den linken Ast ; genommen. RECHTERAST: ... ; Befehle vom rechten Ast... ... ... RTS ; Ende, wir haben den rechten Ast genommen. In diesem Fall verwenden wir eine Testbedingung (TST, Vergleich mit 0, oder CMP, vergleich zwischen zwei Operatoren), gefolgt von einem BEQ (wenn ja, springe...) oder einem BNE (wenn nicht, springe...), um entweder eine Serie von Befehlen auszuführen oder eine andere. Wir haben das BNE schon verwendet, um eine Schleife (LOOP) durchzuführen, in der eine gewisse Anzahl von Instruktionen wiederholt ausgeführt werden, bis nicht eine bestimmte Kondition (Bedingung) eintrifft, zum Beispiel der Mausdruck. Eine Schleife kann man vielleicht besser mit einem Roboter vergleichen, der immer die gleiche Handlung ausführt, auch zig-millionen mal, ohne zu ermüden oder zu streiken: GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND FÜR 30 SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND FÜR 30 SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND FÜR 30 SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND FÜR 30 SEKUNDEN, DANN Es ist wohl recht eindeutig, daß sich ein Mensch rebellieren würde, für die Dauer eines Kuchenbackens dieses Hin und Her ertragen zu müssen. Aber der 68000 macht keinen Mucks, er wiederholt alles, bis der Kuche endlich gar ist, also das BEQ eintritt, und der Roboter zur Routine HOLIHNAUSDEMROHROHNEDIRDIEHÄNDEZUVERBRENNENUNDSTELLIHNAUFDENTISCH:. Ihr werdet schon ahnen, daß mit einigen Verzweigungen hier und da, auch innerhalb mehr oder weniger großen LOOPs, recht komplexe Strukturen entstehen können. Man kann da z.B. an Programme denken, die das Wachsen einer Stadt simulieren und dafür tausende von Bedingungen in Betracht ziehen. All dies ist durch Verzweigungen möglich, die Teils mit sich selbst, Teils mit Schleifen verbunden sind. Die Äste, also die Brocken von Befehlen, die ausgeführt werden, nachdem ein BEQ oder ein BNE eingetreten ist, oder einfach weil sie gerade da waren, als der 68000 vorbeikam, werden ROUTINEN oder SUBROUTINEN genannt. Es sind also Stücke von Programmen, bestehend aus einer Anzahl von Befehlen, die ausgeführt werden, wenn eine bestimmte Aufgabe verlangt wird, bei uns war es der Roboter, der den Kuchen aus dem Rohr holte. Diese Aufgaben können praktisch in eine eigene Routine gelegt werden, die immer dann angesprungen wird, wenn ein Kucken aus dem Rohr zu holen ist. Die Aufgabe von Routinen liegt prinzipiell genau darin, nicht immer einen Teil des Listings neuschreiben zu müssen, wenn z.B. ein Kuchen aus dem Rohr zu holen ist. Wir können also diese Serie von Anweisungen, die dazu notwendig sind, isoliert in eine Routine geben, ihr am Anfang ein Label versetzen und am Ende ein RTS. Geben wir einer Subroutine eine Definition: -SUBROUTINE wird folgende Struktur genannt, die aus einem Block von Befehlen besteht, der von einem LABEL (Belibiger Namen, gefolgt von Doppelpunkten) vorangegangen wird und mit einem speziellem Befehl, dem RTS (ReTurn from Subroutine) endet. Sie wird normalerweise mit einem BSR, gefolgt vom Namen der Subroutine, angesprungen. Nach abarbeiten derselben fährt das Programm in der Zeile unterhalb des aufrufenden BSR weiter. Das alles ist mit dem Käptn eines Unterseebootes vergleichbar, der in diesem Fall das Hauptprogramm darstellt, der durch Verteilen von Ordern gewissermaßen Subroutinen durchführt, z.B. wenn er im Periskop ein feindliches Schiff sieht, wird er ein BSR TorpedosLaden durchführen, also den Befehl geben, die Torpedos scharf zu machen. Bis die Subroutine TorpedosLaden nicht fertig ist, kann er nicht fortfahren. Wenn er dann die Mitteilung erhält, daß diese klar sind, wird er mit der Prozedur fortfahren: BSR SchiffLinks und BSR SchiffRechts, bis es nicht auf der Schußlinie zum gegnerischen Schiff liegt; das kann man mit einer Schleife vergleichen, die mit einem CMP SCHIFF,SCHUßLINIE, gefolgt von einem BNE VERSTELLUBOOT, aufgebaut ist, d.h.: "Ist das Label, die die Position des feindlichen Schiffs enthält, gleich mit dem Label, die die Position enthält, die die Torpedos treffen werden (Schußlinie)?" wenn noch nicht (BNE), dann verstelle noch, also kehre zur Routine zurück, die zuerst erkennt, ob wir zu weit links oder zu weit rechts sind, und dann dementsprechend die Routinen SchiffLinks oder ShiffRechts aufruft. Dies ist mit dem Loop des Roboters vergleichbar, der darauf wartete, daß der Kuchen gar ist, nur müssen wir hier selbst aktiv die Position erreichen, wie beim WarteMaus, bei dem wir die Maustaste drücken mußten, um den Zyklus zu unterbrechen. Wir waren bei der Zielschleife stehengeblieben: auf einmal giebt der Kommandant den Befehl, die Torpedos zu feuern! (BSR SCHUßEINS, BSR SCHUßZWEI). BOOOOOOOOM... Es hat funktioniert... überall liegen Tote rum, Socken schwimmen auf dem Wasser, Witwen und Waisen sind über ganz Deutschland verstreut (in den Kriegsfilmen sterben immer die Deutschen...), ein Relikt am Meeresgrund. RUHIG BLUT! Es war nur eine gute Computersimulation! Wenn ihr nun in die Logik des Prozessors eingegangen seid, dann ist alles in Butter. Alles, was ihr auf dem Computer so laufen seht, sei es nun ein Programm für die Wettervorhersage, ein Demo mit Kuben und Kügelchen, ein Actionspiel, besteht aus Stücken von Programmen, die zyklisch oder sequentiell (in einer Schleife oder Nacheinander) aufeinander abfolgen, je nach Ergebnis der Abfragen wie TST, CMP, BTST. Also ist jede durchgeführte Operation, auch wenn sie noch so kompliziert und komplex erscheint, eine Summe von einfachen Abfragen und Verzweigungen, gefolgt von Anweisungen. Jede Subroutine kann aus vielen, kleineren Subroutinen bestehen, z.B. HOLDENKUCHENAUSDEMROHR: HOLDENKUCHENAUSDEMROHR: BSR SchaltDasRohrAus BSR ÖffneDasRohr BSR NimmDenKuchen (Es ist ja ein Roboter, der verbrennt sich nicht) BSR LegDenKuchenAufDenTisch RTS Jede dieser SubRoutinen kann durch weitere Subroutinen aufgeteilt werden: SchaltDasRohrAus: BSR GehZumSchalter BSR DrehIhnNachLinks RTS Der größte Komfort der SR (Subroutinen) liegt darin, daß man das Programm in logische Teile gliedern kann, die es somit klarer und einfacher gestaten, und daß man Sammlungen von ihnen anlegen kann, die immer wiederverwenden kann, z.B. eine Joystickabfrage. Diese kann man in jedem Spiel einfügen, muß vielleicht einige leichte Änderungen daran vornehmen, aber die größte Arbeit ist getan. Das gleiche gilt für Musikroutinen oder SR, die ein Männchen bewegen. Damit wollte ich euch eine Idee verschaffen, wie der arme Prozessor hin- und hergejagt wird, je nach Ausgang einer Abfrage. Wenn bei diesem Hinundhergehüpfe dann mal ein Fehler auftritt, z.B. fehlerhaft geladene Daten von der Disk oder wo Programmierer versagt hat, dann tritt das mythische GURU MEDITATION bzw. SOFTWARE FAILURE in seinem unheimlich leuchtendem rotem Fenster auf. Der RAM-Speicher kann man beschreiben, er wird, wie schon gesagt, in FAST und CHIP aufgeteilt. Der Unterschied liegt darin, daß Grafiken und SOUND unbedingt in die CHIP-RAM gelegt werden müssen, während Instruktionen für den Prozessor genausogut in FAST wie IN CHIP leben. Z.B. hat der alte A500 mit Kick 1.2 oder 1.3 512kB Ram, und wenn man ihn erweitert insgesamt 1MB, aber die ersten 512kB sind CHIP, die anderen FAST! Deswegen endet der Speicher unter DeluxePaint bei einem A500 mit 1MB schneller als bei einem A500+, der den ganzen 1MB nur CHIP hat. Beim A500 sind die 512kB FastRam übrig, sie sind zum Öffnen von Fenstern ungeeignet, deswegen meldet er, daß kein Speicher mehr frei ist. Wenn man programmiert, und versucht, Grafik in die FAST-RAM zu legen, dann passiert so ziemlich alles, aber es wird keine Grafik angezeigt. Der Speicher ist in Blöcke aufgeteilt, beim A500 geht er von $00000 bis $80000, und die 512kB Erweiterungsspeicher von $c00000 bis $c80000: das Betriebssystem weiß genau, wie der Speicher verteilt ist, und es legt ein Programm, das von der Workbench oder von der CLI/Shell geladen wurde, je nach Anforderung in Chip oder Fast. Danach springt der Prozessor an diesen Punkt und beginnt mit der Abarbeitung. Dem Anwender bleibt aber unklar, wo sein Programm hingeladen wurde und wo der Prozessor gerade arbeitet. Ich ahbe gesagt, daß der Speicher beim A500 von $00000 bis $80000 geht, der Speicher ist in der Tat in Teile zerlegt, wie eine Straße mit vielen Häusern, von denen jedes eine Adresse hat: nicht ohne Grund heißen die Adressen (Adress, in englisch): Am Anfang der Straße ist das Haus mit der Nummer 0, dann Nummer 1, usw. Es wird aber das Hexadezimalsystem verwendet, also mit Basis 16. Aber das ist kein Problem, denn unter dem ASMONE kann man jede Hexziffer sofort konvertieren, indem man den "?" verwendet: ?$80000 ergibt 524288 in Dezimal, also 512*1024, also ein halber kB, "ein halbes Kilo", multipliziert mit 1024 (-> 1kB), das dann einen halben Mega ergibt. $100000 hingegen ist das doppelte, probiert mal ?$80000*2 ("*" -> "Mal", multiplikation). Die Hexzahlen werden von einem Dollarzeichen angeführt, wie ihr gesehen habt, die Dezimalzahlen von nichts, die Binärzahlen von einem %. Diese Dinge sind von grundlegender Bedeutung: so, wie es für die Distanz das Meter, den Dezimeter und den Zentimeter gibt, gibt es für den Speicher des BIT, das BYTE, das WORD und das LONGWORD. Das Bit ist die kleinste Einheit im Speicher. Ein Byte besteht aus 8 Bit, und das ist eine Einheit, die eine Adresse besitzt: Hier kann der Prozessor sagen: Bewege (oder besser: kopiere) das Byte aus dem Haus in der Speicherallee Nr. 10 in das Haus in der Speicherallee Nr. 16. In diesem Fall hat er die acht Bit, die im Byte 10 (also $A in Hexadezimal) enthlaten waren, ins Byte 16 kopiert. Um Durcheinander zu vermeiden, hier das Beispiel in Zeitlupe: die Bit´s können entweder 0 oder 1 sein; die Bit im Byte 10 waren : 00110110, im Byte 16 hingegen 11110010. nach dem MOVE.B 10,16 bleibt das Byte 10, wie es war, und das Byte 16 ist nun 00110110. Das .B nach dem Move deutet an, daß nur ein Byte verschoben wird, also der kleinste Teil, den wir direkt ansprechen können. Man kann auch ein MOVE.W oder ein MOVE.L einsetzen, also ein WORD(.W) oder ein LONGWORD(.L), die nichts anderes sind als: 1 Word = 2 Byte, ein Longword = 4 Byte = 2 Word. Wenn man also ein MOVE.W 10,16 ausführt, dann werden zwei Bytes kopiert: in die Zelle (Adresse) 16 kommt das Byte von Adresse 10, in die Zelle 17 das Byte von Adresse 11. Im Falle eines MOVE.L werden 4 Bytes verstellt: 10->16, 11->17, 12->18, 13->19. Machen wir ein kleines Schema: VOR dem MOVE.B 16,10 08/09/10/11/12/13/14/15/16/17/18/19/20 W O R T P E D A L NACH dem MOVE.B 16,10 08/09/10/11/12/13/14/15/16/17/18/19/20 P O R T P E D A L Wenn wir ein MOVE.L 10,15 08/09/10/11/12/13/14/15/16/17/18/19/20 machen P O R T P O R T A L In unserem Beispiel waren die Adressen 8, 9, 14, 15 leer, also auf NULL, während die Adressen 10-13 und 16-20 Werte (in unserem Fall Buchstaben) enthielten. Beenden wir das Werk mit einem MOVE.W 8,10 und einem MOVE.W 10,12 08/09/10/11/12/13/14/15/16/17/18/19/20 P O R T A L Mit vier Befehlen haben wir WORT PEDAL in PORTAL verwandelt!! Scherz beiseite, fahrt nicht fort bevor ihr nicht in das echte Hirn die Arbeitsweise des synthetischen Hirns geprägt habt! Probiert ein paar Spielchen mit den MOVE.x, das tut euch gut! Probiert zum Beispiel NEGER in REGEN zu verwandeln, oder PAPPIS BART in BARBAPAPA, MEIN HAUS in MEINE MAUS... Erinnert euch,daß Prozessoranweisungen immer an geraden Adressen stehen müssen, wie 2, 4, 6, usw., also an WORD angepasst, sonst geht alles zum GURU... Um euch die Zweifel zu nehmen: im Speicher sind eine Reihe von Werten hintereinander gereiht, ob es nun Prozessorbefehle sind oder Daten für Grafik, Sound, SINUSTAB oder Rollschriften... Im Speicher aber liegen sie nicht als MOVE.B 10,16 vor, das ist eine Disassemblierte Version, in Wirklichkeit sieht dieser Befehl so aus: $13 $F9 $00 $00 $00 $0A $00 $00 $00 $10. Er besteht aus 10 Byte, wobei $13F9 in groben Zügen dem MOVE.B entspricht, $000A der 10 und $00010 der 13 (Hex 0A= 10 dezimal, Hex 10 = 16 dezimal). Auf diese Art besitzt jede Operation ein Bytemuster im Speicher, sogar NOP, No Operation, -> keine Operation, tut nix, hat eines:$4e71. Vorausgreifend möchte ich sagen, daß der Prozessor, außer auf den Speicher zuzugreifen, auch noch Register besitzt: Datenregister und Adressregister. Insgesamt sind es 16 und jedes ist ein Longword lang (4 Byte). Die Adressregister heißen A0, A1, A2, A3, A4, A5, A6, A7, die Datenregister D0, D1, D2, D3, D4, D5, D6, D7. Da sich die Registrer innerhalb des Prozessors befinden, sind sie sehr schnell, auf jeden Fall schneller, als der Speicher. So ist die Operation MOVE.L d0,d1 schneller als MOVE.L $100,$200, man bevorzugt also jene, die mit Registern arbeiten. Die ROM - wie schon gesagt- kann man nicht beschreiben, ein MOVE, das dorthin schreibt bleibt also effektlos: ein MOVE auf $FC0000 oder auf $F80000 ist für gar nichts gut. Es ist nur möglich, Routinen auszuführen, die in der ROM gespeichert sind. Da aber bei jeder Version der Kick ANDERS ist, darf man ihn NIE DIREKT anspringen. Das Betriebssystem ist so ausgelegt, daß jede Routine, also Programmstück, das in im Kickstart enthalten ist, auf die gleiche Art aufgerufen werden kann, egal, um welche Version es sich handelt und wo im Speicher sie sich befindet: das wird mit einem JSR, oder JUMP TO SUBROUTINE (Spring zu Adresse xxxx, dann kehre unter das JSR zurück und fahre dort weiter), gemacht. Die "Schrittweiten" für die JSR der verschiedenen SR sind fix, starten aber immer bei der Adresse, die in Adresse 4 enthalten ist. In der Adresse 4 ist also die richtige Adresse eingetragen, ab welcher sich die SR befinden, und man muß sich IMMER daran halten, um Routinen des Kickstarts verwenden zu können. Die Programme, die WorkBench-Fenster öffnen, Buchstaben auf den Bildschirm schreiben oder Files von einer Disk lesen oder auf eine Disk schreiben, müssen jedesmal auf solche SR im Chip des Kick zugreifen, und ihnen z.B. den Namen des Files übermitteln, den man öffnen möckte oder die Größe des Fensters... Wenn ein Spiel, ein Programm oder ein Demo das Betriebssystem überspringt, es also nicht verwendet, dann werden keine Aufrufe zum Kickstart gemacht. Ein Beispiel ist das bekannte XCopy, das einen eigenen Screen öffnet, eindeutig das Multitasking über den Haufen wirft, keine WorkBenchfenster hat und auch keine Rechte-Maus-Taste-Menüs, wie sie aus dem AmigaDOS bekannt sind. Genauso würde ein Spiel, wie ich einige vorher angeführt habe, z.B. SENSIBLE SOCCER, funktionien, wenn man den Kickstart nach dem BOOT (Start) entfernen würde, da es keine Routinen aufgerufen werden, die ein File laden oder ein Fenster öffnen. Die Dinge, die am Bildschirm erscheinen, werden Eins nach dem anderen kontrolliert, und die Daten werden nicht als DOS-Files von der Diskette geladen, sondern als Spuren, die direkt über den Lesekopf eingelesen werden, der wiederum "von Hand" gesteuert wird, indem man an den verschiedenen Pin des DRIVE Spannung anlegt oder nicht (natürlich softwaremäßig). Leuchtet diese Differenz ein?? Zwischen Programmen und Spielen, die dauernd Kickstart-Routinen verwenden, deswegen in Multitasking laufen und den Programmen, die keine Fenster verwenden, oder zumindest nicht die der Workbench, und nicht mit DeluxePaint im Hintergrund laufen, und die es nicht erlauben, zwischen den Applikationen umzuschalten oder einfach das Fenster herunterzuziehen?? Kurzum, die ROM kümmert sich darum, für uns mit der HARDWARE in Kommunikation zu bleiben, und sie führt einige vordefinierte Dinge aus, aber wenn wir beschließen, selbst mit der Hardware in Kontakt zu treten, können wir alles Mögliche tun, Hauptsache, wir sind es im Stande!!! Wir werden uns daum bemühen, Code ohne ROM-Unterstützung zu erzeugen. Aber dann verwenden wir nur den Prozessor? Und wie zeigt man da eine Grafik an oder läßt Musik spielen? Mit vielen MOVE??? Jetzt kommen die CUSTOM-CHIPS ins Spiel!! Diese Chips heißen PAULA, AGNUS und DENISE, außerdem noch zwei weitere, CIAA und CIAB genannt. Diese Schlaumeier sind dafür zuständig, den Amiga aufspielen zu lassen und die Farben auf den Schirm zu bringen. Die meisten Register, die zu deren Kontrolle notwendig sind, befinden sich auf den Adressen zwischen $DFF000 und $DFF1FE, die anderen, die mit den Serialund Parallelport und den Disk Drive zu tun haben, sitzen auf $BFExxx und $BFDxxx. Wenn man einmal die Befehle des 68000 gelernt hat, kann man Programme so groß wie einen Berg schreiben, aber es wird noch nichts angezeigt oder gespielt. Mit dem Prozessor muß man diese Chips ansteuern; einer davon ist der BLITTER, der die Aufgabe hat, Linien zu zeichnen, Speicherstücke wie Scrolls oder Männchen auf dem Bildschirm rumzukopieren, Flächen zu füllen (Die 3d Körper werden mit dem Blitter gezeichnet und gefüllt; der Prozessor kümmert sich nur darum, die Koordinaten zu errechnen, den Rest macht der Blitter). Derjenige, der jedoch alles anzeigt und die Farben bestimmt ist der COPPER: um ein Beispiel zu machen, $DFF180 entspricht der Farbe 0, $DFF182 der Farbe 2, während in $DFF006 die Linie gespeichert ist, die der Elektronenstrahl gerade auf den Bildschirm malt. Dieser wird 50 mal in der Sekunde neu erstellt. Diese Register sind entweder nur zum Lesen oder nur zum Schreiben: in das Register $DFF180 kann man nur einen Wert hineinschreiben, aber keinen auslesen (um zu erfahren, welche Farbe gerade Farbe 0 ist...), während $DFF006 nur lesbar ist. Um die Position des Elektronenstrahls zu verändern gibt es aber ein bestimmtes Register, genauso wie für viele andere. Mit den Registern $BFExxx kann man die Ports kontrollieren, unter anderem die Maus: z.B. entspricht Bit 6 der Adresse $BFE001 dem Status des linken Mausknopfes, ob er gedrückt ist oder nicht. Man kann dieses Bit mittels Prozessors kontrollieren und abwarten, bis der Mausknopf gedrückt wird, bevor das Programm verlassen wird. Und das wird das erste Beispiel des Kurses sein, das Du analysieren kannst, indem Du Lektion1a.s ladest. Es beinhaltet eine Schleife mit dem 68000, die Verwendung eines $DFFxxx-Registers und eines $BFExxx-Registers. Ladet es in einen anderen Textbuffer, wie weiter unten erklärt. Eine kleine Anmerkung, wie man den Assembler - in unserem Fall den ASMONE -verwendet: Am Anfang wird man entscheiden, ob CHIP- oder FAST-Speicher reserviert werden soll. Für die Beispiele des Kurses sollte CHIP-RAM gewählt werden, jenachdem wieviel ihr habt, aber mindestens 250kB. Um eine Directory oder ein anderes Laufwerk auszuwählen, tippe "V", z.B. um in die Directory der Lektionen zu kommen, tippt "V df0:Lektionen", um in die Directory der Listings zu gelangen "V df0:Listings". Um nun ein Listing zu lesen, gibt es den Befehl "R". Wählt ein Listing im Fenster aus. Mit ESC wechselt man zwichen Editor und Kommandozeile. Drückt also ESC, und ihr könnt das Listing verändern, dann nochmal, und ihr seit wieder in der Kommandozeile, wo ihr das Listing ASSEMBLIEREN könnt. Dafür verwendet den Befehl "A" (wie "Assemblieren"...), danach, um es auszuführen, "J", wie "JSR"!! Ihr könnt bis zu 10 Texte gleichzeitig laden, wenn ihr im EDIT-Modus seit, könnt ihr mit den Tasten F1...F10 zwischen den verschiedenen Textbuffern (Textfenstern) herumspringen. So könnt ihr im Ersten die Lektion1.TXT laden, im zweiten (F2) das erste Beispiel, Listing1a.s, im Dritten (F3) das nächste (Listing1b.s) usw. Wenn ihr was vergessen habt, könnt ihr mit F1 wieder zum Text springen und nachlesen. Anmerkung: um seitenweise rauf oder runter zu gehen, verwendet die Pfeiltasten + SHIFT, für die, die keinen C64 hatten, es ist die große Taste über ALT, die mit dem Pfeil. Nun erkläre ich euch, was passiert, wenn ihr "A" eingebt: das Listing (oder Source-Code) ist in stinknormalem Textformat und besteht aus Schlüsselworten, die die Befehle sind oder anderen Zeichen, die der Assembler kennt. Um eine Gruppe von Befehlen, eine "Variabel", den Beginn einer Tabelle zu kennzeichnen oder jeglichen Anhaltspunkt im Listing zu haben, werden Namen mit Doppelpunkten vergeben, eben dem LABEL oder ETIKETTEN. Der Name des Label kann beliebig sein, er darf aber nicht gleich einem 68000er Befehl sein!! Beispiel: WAITMOUSE: ;das Label btst #6,$bfe001 ;Linke Taste gedrückt? bne.s WAITMOUSE ;wenn nicht, zurück zu WAITMOUSE ;(wiederhole das btst) RTS ;Ende, steig aus Ich erinnere euch daran, daß die von Befehle mindestens einer Leerstelle vorangegangen werden müssen. Ich habe ein TAB genommen, das gleich 8 Leerzeichen auf einem Schlag erledigt. Achtet auch darauf, daß KEINE Doppelpunkte gesetzt werden, wenn ein LABEL aufgerufen wird, NUR wenn sie selbst erzeugt wird. Also, einmal editiert wird das Listing assembliert, das geschieht durch "A"; diese Operation läßt den ASMONE den Text lesen, und der verwandelt ihn in CODE, den der 68000er lesen kann. Einmal assembliert, ist der Code in einem Teil des Speichers, der mit "=R" gelesen werden kann, und mit "J" springt der Prozessor auf diesen Punkt und führt unser Programm aus. Wenn vom ASMONE ein Fehler gefunden wird, assembliert er nicht zu Ende, bis der Fehler nicht behoben wurde. Die Listings, die im Kurs enthalten sind, funktionieren auch mit anderen Assemblern, wie dem DEVPAC3 oder dem MASTERSEKA, mit allen Kickstart und mit allen Amigas, auch denen mit dem AGA-Chipset, den A1200 und dem A4000. Wenn ihr die Funktion von Listing1a.s überprüft habt, ladet "Lektion2.TXT" in einen anderen Textbuffer (F3, z.B). Verwendet dazu "R". Sollte es an Speicher mangeln, wenn ihr zwischen den Buffern herumschaltet, dann bedeutet das, daß ihr am Anfang (bei ALLOCATE), zuviel reserviert habt, und euch nicht genug für die RAM DISK übrig geblieben ist. Wählt das nächste Mal weniger aus.